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INTRODUCTION 

The Software Dispatch Review is a compendium of information 
which provides a customer with a maintenance notebook on 
current software documentation and the status of known soft¬ 
ware problems. The notebook is supplemented with articles 
in the monthly Software Dispatch which should be filed in 
the appropriate sections of the Software Dispatch Review. 

It is recommended that users make all the published patches. 
Users with source files are asked to make the indicated 
source level changes and suitably update their software 
system. 

FILING 

This introductory material should be filed at the beginning 
of the notebook. 

A system has been devised to help you file each article in 
its proper place. The key is the following figures 
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VERS 
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0 
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(2) 

VERSION 

(2A) 

EDIT 

(2B) 

SUBPROGRAM OR ADDITIONAL INFORMATION 

(20 

SEQUENCE 

(3) 

PAGE 

OF 

(3A) 


NEW REPLACE 

j!n 

rMENT 

(5) 

ARTICLE 

ORIGINAL DATE 

(5A) 


Coding Block. 

Each month the Software Dispatch should be taken apart and 
inserted into the notebook. 

Firsts the articles are classified by software product (1). 
All articles should be filed under the appropriate major 
heading. 

Secondly, the software product is broken down by its compo¬ 
nents (2)» See section 2.1 for the list of software 
components. 
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Articles pertain to the program with the latest version (2A) 
or edit (2B)* whichever is applicable. Source level changes 
will always affect the edit* 

All programs which print out their version number do so initially 
as VlAOOOe A new update release would cause the letter to be 
changed to "B" * This is the major release level of the monitor. 
Whether a change to a program is given as a source change#- the 
three digit code in the version number is incremented by one; 
e.g.* V1A001. 

Finally, the article is referenced by sequence number (3). 

As an article is added to each component* it is assigned the 
next higher sequence number. 

Additional information in the coding block is presented to 
further clarify the article and is not specifically for 
filing; 

(1A) Version of the software product. 

(2A) Version number of the component. 

(2B) Edit number. 

(2C) Other information helpful to the user. 

(3A) Page number and pages in the article. 

(4) An "X" in this block indicates a new article. 

(5) A number in this block indicates an article republished 
for revision or correction and specifies the number of 
the revision. For example* the second revision of an 
article which originally appeared in June 1974 is shown 
in the following figure. 

(5A) Original date of a revised article. 


[ NEW 

REPLACEMENT ARTICLE 

ORIGINAL DATE 




2 


June 1974 


Coding block showing the second revision. 
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2•1 System Components 

Articles concerning changes to manuals will be coded and filed 
along with changes to programs* For example, an article con¬ 
taining a change to the CHAIN program could be followed by an 
article amending the CHAIN and EXECUTE manual* Changes to the 
monitor manuals and other general system documents will appear 
under the code Monitor* 
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RP Disk Handlers 
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RKL* 
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System 

Save/Restore Program 

DUMP 

EDITOR 
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EDITVT 

FOCAL 


FOCAL 
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FORTRAN 


General FORTRAN Issues 
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FORTRAN COMPILER 


FORTRAN OTS 


LINKING LOADER 

.LOAD 

LINE PRINTER HANDLERS 

LPA.15 


LPU* 

LK35 KEYBOARD HANDLER 

LKA 

MACRO XVM 

MACRO 


CREF 

MCLOAD 

MACIMG 

MACH 

MACINT 


Mil .8 


Mil.12 

MAGTAPE 

MTAo 


MTCo 


MTDUMP 


MTF e 

MONITOR 

DOSNRM 


RESMON 

PAPERTAPE PUNCH HANDLERS 

PPA 


PPB 


PPC 

PAPERTAPE READER HANDLERS PRA 


PRB. 

PATCH 


PIP 


PIREX 


PLOTTER HANDLER 

XYA a 

QDMP XVM 


QFILE 


SPLGEN 


SPLOAD 

SPLIMG 

SPOOL 

SPOL15 


SPOLll 

SRCCOM 


SYSTEM 



SGEN 


SYSTEM LOADER 

.SYSLD 

UDMP11 


UPDATE 


VP15 GRAPHICS 

VPA® 


VPA.S 

FORT 

NUVAL 

VECTOR 


Compiler 

Object time system 
Utility routines 
Relocatable file loader 
XVM Line Printer Handler 
PDP-11 Line Printer Handler 

XVM Assembler 

Cross reference program 


Magtape handler 
Magtape handler 

Magtape handler 
Nonresident MONITOR 
Resident Monitor 


PDP-11 Peripheral 
Processor Executive 
Plotter Handler for XY11/XY311 
XVM Core Dumper 


All system information that 
does not fall under any 
other component will 
appear here. 

System Program Loader 
PDP-11 Core Dumper 
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VT15 GRAPHICS 


WRITING TABLET 

8TRAN 

BOSS 

BOSS PROCEDURE 


VTA* 

VTPRIM 

LTORPB 

DYLDR 

TRACK 

ROTATE 

CIRCLE 

HANDLER VWA, 

BoPRE 

NRBOSS 

FILE 


Preprocessor 
Nonresident monitor 
The additional information 
may contain any of the 
procedure files listed in 
the BOSS XVM Users Manual * 
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2.2 Version Numbers and Support Categories 


Language & Utilities Device Handlers 
Category 1 Category 1 


Program 

Version 

Program 

Edit Number 

ABSL11 

(EDIT) 103 

BOOTSTRAPS 

BOSS 

VlAOOO 

RFBOOT 

017 

CHAIN 

V1A000 

RKBOOT 

020 

DDT 

V1A000 

RPBOOT 

009 

DOSSAV 

VIA 000 

CARD READER HANDLERS 

DUMP 

V1A000 

CD.DOS 

134 

EDITOR 

V1AOOO 

DECTAPE HANDLERS 

EDITVP 

V1A000 

DTA. 

129 

EDITVT 

VIA000 

DTC. 

103 

EXECUTE 

V1AOOO 

DTD. 

108 

FOCAL 

V1A000 

DTE. 

108 

FORTRAN 

V1A000 

DTFo 

108 

LOADER 

VlAOOO 

DISK HANDLERS 

MACRO XVM 

V1A000 

DOSRFA 

159 

MACH 

VlAOOO 

LINE PRINTER HANDLERS 

MTDUMP 

VlAOOO 

LPA.15 

150 

PATCH 

VlAOOO 

LPU. 

124 

PIP 

VlAOOO 

LK35 KEYBOARD HANDLER 

PIREX 

154 

LKA. 

002 

SPLGEN 

VlAOOO 

MAGTAPE HANDLERS 

SPLOAD 

VlAOOO 

MTA. 

108 

SPOOL 

VlAOOO 

MTC. 

101 

SGEN 

VlAOOO 

MTF. 

114 

SRCCOM 

VlAOOO 

PAPERTAPE 

PUNCH HANDLERS 

UPDATE 

VlAOOO 

PPAo 

102 

8TRAN 

VlAOOO 

PPB. 

101 



PPC. 

101 



PAPERTAPE 

READER HANDLERS 



PRAo 

100 



PRB. 

100 


PLOTTER HANDLER 
XYU, 036 

VP15 GRAPHICS HANDLER 
VPA o 113 

VT15 GRAPHICS HANDLER 
VTA. 006 

WRITING TABLET HANDLER 
VWA. 005 


Monitors 
Category 1 
Program Version 

XVM/DOS V1A000 
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2•3 System Documentation 








2*3*1 General System Manuals 


Order Code 


BOSS XVM USERS MANUAL 
XVM/DOS USERS MANUAL 
XVM/DOS SYSTEM MANUAL 
XVM/DOS KEYBOARD COMMAND GUIDE 
XVM UNICHANNEL SOFTWARE MANUAL 
SGEN XVM UTILITY MANUAL 
XVM/DOS READ ME FIRST USERS GUIDE AND 
MASTER INDEX 

XVM/DOS VIA SYSTEM INSTALLATION GUIDE 


DEC-XV™OBUAA™A™D 
DEC™XV™ODMAA™A~D 
DEC™ XV™ODSAA™ A™D 
DEC-XM-ODKBA™A™ D 
DEC™XV™XUXMA™A™D 
DEC-XV-USUTA-A-D 

DEC™XV-ODGIA-A™D 

DEC™XV™ODSIA™A™D 


2*3*2 Language Manuals 

FORTRAN IV XVM LANGUAGE MANUAL 
FORTRAN IV XVM OPERATING ENVIRONMENT 
MANUAL 

FOCAL XVM LANGUAGE MANUAL 

MACRO XVM ASSEMBLER LANGUAGE MANUAL 

MACH XVM ASSEMBLER LANGUAGE MANUAL 

2*3*3 Utility Programs 

CHAIN XVM/EXECUTE XVM UTILITY MANUAL 
DDT XVM UTILITY MANUAL 
EDIT/EDITVP/EDITVT XVM UTILITY MANUAL 
LINKING LOADER XVM UTILITY MANUAL 

MTDUMP XVM UTILITY MANUAL 

PATCH XVM UTILITY MANUAL 

PIP XVM UTILITY MANUAL 

SRC COM XVM UTILITY MANUAL 

UPDATE XVM UTILITY MANUAL 

VP15A XVM GRAPHICS SOFTWARE MANUAL 

VT15 XVM GRAPHICS SOFTWARE MANUAL 

8TRAN XVM UTILITY MANUAL 


DEC-XV™LF4MA™A™D 

DEC-XV-LF4EA-A-D 
DEC~XV™LFLGA~A~D 
DE C~XV™LMACA-A-D 
DEC~XV™LMLAA™A~D 


DEC™XV™UCHNA~A™D 
DEC™ XV-UDDTA™A™D 
DEC™XV~UETUA™A™D 
DEC~XV-ULLUA™A-D 

DEC-XV-UMTUA-A-D 
DE C™ XV™UPUMA~A™D 
DEC~XV-UPPUA~A™D 
DEC™ XV-US RCA™A™ D 
DE C™XV™UUPDA™A™D 
DEC-XV™GVPAA™A™D 
DEC“XV™GVTAA™A™D 
DEC»XV™UTRNA™A™D 


9 
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3.0 SOFTWARE PERFORMANCE REPORTS 

Each new installation is provided with Software Performance 
Report (SPR) forms. The SPR form enables users to suggest 
enhancements to or report problems with Digital Equipment 
Corporation software or documentation. When a problem is 
encountered* an SPR should be completed and mailed to the 
local SPR Center. (See inside back cover.) 

Responses will be sent to the name and address appearing on 
the form. Additional SPR forms may be obtained by writing 
to the local SPR Center. 

3.1 Software Performance Report Guidelines 

The following is a guideline for completing Software Performance 
Reports (SPRs) so that adequate information is included. 

For all XVM/DOS systems* please completely fill out the SPR 
form. Subscription and warranty customers must enter their 
system serial number on the SPR form. It is important that 
we know the machine configuration—including the system disk 
type* the amount of core in use and the peripherals on the 
machine. The name and version number of the system program 
in use* if any* is absolutely essential. An adequate and 
clear description of the problem is very important and will 
certainly speed processing of the SPR. Two of the best ways 
of supplementing the description is to include the terminal 
printout that shows the problem as well as an actual copy of 

the user program that caused the problem if one is involved. 
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Further, UNICHANNEL”-15 should include this additional information, 
if possibles 

L The UNICHANNEL-15 configuration, including the core 
size of the PDP-11 and PDP-11 peripherals® 

2® The assembly parameters used to create the PIREX and 
SPOOLER in use® 

3o A listing of PIREX or SPOOLER if any user modifications 
have been made® 

4® A dump of both PDP-11 core (use UDMP11) and XVM core 

(use QDMP XVM). UDMP11 requires an LP11/LS11/LV11 line 
printer * 
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4e 0 XVM/DOS VIA SYSTEM NOTES 


BOOTSTRAP 

Programming Note Regarding .GET & PUT MACROS 
BOSS 

Restrictions in $CRT and $ADD Usage 
CARD READER HANDLER 

Error Messages for PDP-15 NONUNICHANNEL CARD 
READERS 

CHAIN 

Notes on the Operation of CHAIN 
Multiple Entry Points Handled Incorrectly 
in Overlays 

DECTAPE HANDLERS 

Reading Beyond End-of-File 

Support of „TRAN Function on PDP-8/10/11 Tapes 

DISK HANDLERS 
Renaming Files 

FORTRAN 

Usage Restriction and Precaution 
Use of ADSS vs XVM/DOS Magtape Handler MTF 
A Change in the Handling of Carriage Control 
Characters in Nonprinter Devices by the 
FORTRAN Object Time Routine BCDIO 
Programming Note to Eliminate Carriage Return 
Using System Buffers for FORTRAN OTS Double 
Buffering 

FORTRAN COMPILER 

Modes of Statement Function Variables 
Programming to Avoid Incorrect Mode Typing of 
Functions Declared EXTERNAL 
Variables Declared INTEGER are Typed as LOGICAL 
DOUBLE INTEGER Literals Incorrectly Defined 
Transferring Control to a FORMAT Statement 
Restriction of Variables in Named COMMON 
Displaced Error Reports 
End of Compilation Message 


Sequence 


It 


It 


It 


It 

2 


It 

2t 


1 


It 

2 + 


3 

4t 

5 


It 

2t 

3t 

4t 

5t 

6t 

7t 

8 


tReplacement Article. 
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Sequence 

FORTRAN OTS 

Programming Note Regarding Argument Address 

GET Routine, .DA It 

Numerical Restriction in AMOD and DMOD 2t 

IOPS31 Errors When Referencing the Last 

Element of an Array 3 

First Character of Each Record Sometimes 

Truncated On Mass Storage Files A 

LINKING LOADER 

Programming Note 1 

Incomplete Loading of Subroutines with Multiple 

Entry Points 2 

BATCH .DAT Slots 3 

BATCH I/O Device Use 4 

System Build Leaves Erroneous .DAT Assignment 5 

MACRO XVM 

Programming Note on Use of T Switch It 

MACRO E Switch Does Not Give Correct Lines in 

Console Device Under BOSS 2 

Edits to Bring MACRO to XVM/RSX Release Level 3 

MONITOR 

Teletype Handler .INIT Function Limitations It 

.DAT -12 Set Up 2 

PATCH 

MICLOG Before Patching on Disk 1 

FORTRAN Programs Cannot be Made System Programs 2 

PIP 

IOPSO after (H) Copy to System Disk 1 

SYSTEM 

Conversion from ADSS-15: Programs May Not Fit 1 

Using API Level 4 2 

System Manual Not Complete 3 


tReplacement Article. 
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Programming Note Regarding .GET & .PUT MACROS 


The unit number field in an object code product before XVM/DOS 
VlAOOO with .GET and .PUT monitor calls is ignored in the XVM/ 
DOS system.' +Q AREAS will be utilized if present only on the 
current system device unit 0. XVM/DOS .GET/.PUT MACROS do 
not allow unit number fields. 
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Restrictions in $CRT and $ADD Usage 


PROBLEM: 

The following sequence of cards causes BOSS XVM to crash 
with an I0PS11 error. 


$ADD XYZ 
$ADD YYY 

or 

$CRT XYZ 
$CRT YYY 


RESTRICTION: 

Two $ADD cards or $CRT cards cannot be adjacent. The 
system will not handle this properly. 

A user can get around this by inserting any legal BOSS 
command card(s) other than $CRT, $ADD, $JOB and $END 
between the two cards. 
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SOFTWARE DISFATCH 


Error Messages for PDP-15/XVM NON-UNICHANNEL CARD READERS 


When a hopper-empty, stacker-full or reader-not-ready 
condition arises, the following message is printed: 

I0PS4 CD NOT READY 

To recover, clear the condition, ready the reader, and 
type CTRL R. 

If a card with an illegal punch is encountered the following 
message is printed: 

I0PS4 CD-ILLEGAL PUNCH 

To recover, punch a correct card, discard the incorrect 
card, place the new card in the input hopper , and type 
CTRL R to continue. 
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Notes on the Operation of CHAIN 


1. Routines or subroutines declared as part of the resident 
code by using the library indicator (#) in the command 
string are entered into a dummy global symbol table. 

Hence, it is necessary for a ".GLOBL name" identical 

to the name accompanying the "#" to be present within 
the routine to be called. An identical file name is 
not sufficient; in fact, file names are ignored when 
searching for library indicator (f) routines. In the 
absence of this declaration, the error message 
"UNRESOLVED GLOBAL" will result. 

2. CHAIN scans the user library (.LIBR5) before scanning 
the system library (.LIBR) to load library routines 
and satisfy unresolved globals. 

3. CHAIN resolves globals in a manner similar to the 
LINKING LOADER. 

Restrictions in building an overlay structure: 

Pages 7-5 through 7-8 of the Chain/Execute Manual define a set 
of rules that govern the building of an overlay structure 
through the (definition of links a.nd structures«, 

There are a few overlay structures that cannot be defined 
within the framework of these rules® Any attempt to define 
one of these overlay structures will result in the printout 
of any one of the appropriate error messages® 

An example of one such overlay structure that cannot be 
built follows : 
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Multiple Entry Points Handled Incorrectly in Overlays 


PROBLEM: 

When used in overlays, program units with multiple entry points 
cause DUPLICATE GLOBAL DEF or UNRESOLVED GLOBAL errors to be 
output by CHAIN. 


RESTRICTION: 

Program units with multiple entry points can not be placed 
in overlays but must be placed in the resident code. 



SOFTWARE PRODUCT 

XVM/DOS 

VERS 

V1A( 

ION 

)00 

COMPONENT 

CHAIN 

VERSION 

V1A000 

EDIT 

179 

SUBPROGRAM OR ADDITIONAL INFORMATION 

SEQUENCE 

2 

PAGE 

OF 

1 1 


NEW 

X 

REPLACEMENT ARTICLE 

□ 

ORIGINAL DATE 

March 1976 


25 







XVM/DOS 




Reading Beyond End-of-File 

The last block of a file on DECtape has a forward data link 
of 777777. If the user tries to read past this block, DTA 
will return the end-of-file sequence (0010)35,776773) in the 
user buffer. Subsequent .READS will continue to pass back 
the same two words. This corrects a problem that occurred 
in PIP when reading in dump mode and when the 001005,776773 
sequence was part of the data being transferred, with still 
more data following it. 


NOTE: The above change has not been made to the DTC., 

DTD., DTE., or DTF. DECtape Handlers. 
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.TRAN Function on PDP-8/10/11 Tapes 


The DECtape handlers in the system (except for DTC. and DTF.) 
can be utilized to transfer data from PDP-8/10/11 tapes 
usinq the .TRAN function. 

In order to realize the above, a minor source modification 
is needed. The instruction, 

AND (7777 /clear possible erroneous data 

must be inserted after the location DTSRCK+2, i.e., after the 
instruction, 

LAC DTBCA 

in DTA., DTD. & DTE. 

This is necessary because these tapes have 12-bit block 
numbers with extraneous data in the most significant bits. 

Note that since the file structure on these tapes is different 
from the XVM/DOS file structure, only.the .TRAN function can 
be used. 

This information is provided for the user's convenience only 
and is not a feature supported by DEC. 
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Renaming Files 


PROBLEM: 

All Disk Handlers allow a file to be renamed to the same name 
as an existing file. 




DISPOSITION: 

Should this happen, use PIP to rename the files, noting that 
PIP will always access the first file it finds m a directory 
with the specified name. 
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Usage Restriction and Precaution 


PROBLEM: 

The FORTRAN IV Language Manual DEC-XV-LF4MA-A-D describes the 
usage of object time FORMAT specifications. It is not allowed, 
however, to use the name of an array that appears in a SUBROUTINE 
statement parameter list as an array name that is referenced 
by an I/O statement; that is, in the following program, the 
construction is correct. 

DIMENSION IBUF(10),FORM(10) 

DATA FORM(1) /5H(4I10/ 

DATA FORM(2) /5H) / 

DO 10 I = 1,10 
10 IBUF(I) = I 
NSZ=4 

WRITE (6,FORM) (IBUF(I),1=1,NSZ) 

CALL PRINT (IBUF,NSZ,FORM) 

PAUSE 

END 

The first four elements of IBUF will be printed according to the format 
specified in the array FORM. If this is attempted in the subroutine PRINT, 
shown below, an OTS 12 will occur. 

SUBROUTINE PRINT (IBUF,NSZ,FORM) 

DIMENSION IBUF(1), FORM(10) 

WRITE (6,3) (FORM(I),1=1,10) 

3 FORMAT(IX,10A5) 

WRITE (6,FORM) (IBUF(I),1=1,NSZ) 

RETURN 

END 
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SOFTWARE DISRMCH 


Usage Restriction and Precaution 


To avoid this problem, it would be necessary to create some array in PRINT 
and to copy FORM into it. The former array could then be specified in the 
WRITE statement. 


As a further precaution, always enclose your FORMAT specification in parentheses 
when using this technique. Note that this was done in the DATA statement of 
the main program on the previous page. 
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Use of ADSS vs XVM/DOS Magtape Handler MTF 


PROBLEMS 

l e The MTF. handler released with ADSS-15 V5A does not calculate checksums 
for IOPS binary records* MTF* released with XVM/DOS does calculate 
checksums* Users attempting to read old data tapes under XVM/DOS FORTRAN 
may run into problems* 

2- Under XVM/DOS' MTF* has a default buffer size of 255| 0 * The ADSS-15 
version has a fixed buffer size of 56 10 . 

3- The buffer size in XVM/DOS MTF„ may be changed under program control 
by referencing the global "MTBSIZ." (See XVM/DOS Users Manual*) 

4* Under XVM/DOS s MTF. checks for record-length errors prior to calculating 
checksums; and, if the record length is less than 255 (i.e., 56), MTF. 
returns to the user without calculating a checksum. 

5. MTA and MTF generate EOF in the same mode as the current 

data transfer mode. This may cause some problems in applications 
written prior to D0S-V3B„ 


The above inconsistencies create the following possibilities when reading old 
data tapes under XVM/DOS FORTRAN and MTF. 



MTBSIZ 

OTS 

Error 

Data 

Read In 

•One physicaJ record 
per logical record 

255! o 

None 

Good 

56 10 

ii 

— 

More than one physical Record 
per logical record 

2551 o 

None 

Bad 

56io 

11 

— 


I ------ 
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Use of ADSS-15 vs XVM/DOS Magtape Handler MTF 


SOLUTIONS 

The user may copy an old data tape using the following program. 

10 CALL SET56 

READ (1, END = 11) LIST 
CALL SET255 
WRITE (2) LIST 
GO TO 10 

11 CALL SET255 
WRITE (2) LIST 
CALL CLOSE (1) 

CALL CLOSE (2) 

STOP 

END 

SET56 and SET255 are two MACRO XVM subroutines: 

.GLOBL SET56,MTBSIZ,.FM 


SET56 0 

LAC (70) 

DAC* MTBSIZ 
DAC* .FM 
JMP* SET56 
.END 

.GLOBL SET255,MTBSIZ,.FM 

SET255 0 

LAC (377) 

DAC* MTBSIZ 
DAC* .FM 
JMP* SET255 
.END 


NOTEs Do not modify these programs. Insure that tapes are at load point 
before starting. 
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XVM/DOS 


A Change in the Handling of Carriage Control Characters on 
Nonprinter Devices by the FORTRAN Object Time Routine BCDIO 


HISTORY t Operation on DOS VIA, DOS V2A, and RSX PLUS III 

The PDP-15 FORTRAN I/O system has always had a somewhat incon¬ 
venient behavior concerning the first character (the carriage 
control character) of formatted ASCII records e The BCDIO pro¬ 
gram, which actually builds or decodes the output or input 
lines under control of the specified FORMAT statement, always 
interpreted the first character of each output record as a 
carriage control character. Upon output, BCDIO examined the 
first character placed in the buffer and always performed the 
following translations 


Character Found 

Translated to 

Meaning to LP Handler 

1 1 9 

hrj 

H 

00 

Skip to top of form 

8 -f 1 

DLE, 20q 

Overprint 

*0* 

DC1, 21g 

Double space 

0 5 (space) 

LF, 12g 

Single space 

anything else 

LF, 12g 

Single space 


The implications of this method are obvious? Output to the 
line printer end console terminal worked as desired? output 
to the papertape punch was good, since a more or less standard 
format for ASCII paper tape is LF-data-CR. However, disk, 
DECtape, and magtape files also had a carriage control char¬ 
acter preceding each record; or, if the unwary user did not 
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A Change in the Handling of Carriage Control Characters on 
Nonprinter Devices by the FORTRAN Object Time Routine BCDIO 


provide a space to be used for carriage control, the first 
character of his data was lost. 


This action is documented in the footnote on page 6-5 of the 
FORTRAN Language Manual, DEC-XV-LF4MA-A-D. 


On input, when BCDIO was decoding an input line, it first 
dropped line feeds, form feeds, etc. (actually it dropped 
any character less than 40 ). No action was taken when there 
was no leading line feed character. 


The conclusion to all of this is that: 


1. On output, the first character of each line was trans¬ 
lated by BCDIO: 

First Character Translated to Meaning 


'l 1 

> 0 ' 

9 9 (space) 

any other 


FF, 14 8 
DCl f 21g 
DDE , 20 
LFf 12 8 
LF, 12g 


8 


Skip to top of form 
Double space 
Overprint 
Single space 
Single space 


before the line was written to any device. 
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2. An extra character position must have been provided in 
FORMAT statements even when the intended destination de¬ 
vice was a mass storage unit. For example: 

WRITE (3,100) A,B,C 

100 FORMAT (IX,3F6.2) 

This was to prevent BCDIO from destroying the first 
data digit. 

3. Since carriage control character translations always 

occurred, a program which produced a report intended for 
the line printer or console terminal which used forms con¬ 
trol characters 1 1', ' + ? or '0 1 in addition to ' ' produced 

a PIPable file if the .DAT slot normally used for the printer 
was assigned to a disk. In other words, if a disk was 
assigned rather than a line printer, a file was created 

by the OTS which contained the translated listing if the 
file were PIPed to the printer. 

4. A different FORMAT statement was needed to read a record 
than was used to write the record. The input FORMAT 
needed to describe a record which was one character is 
shorter (specifically, missing the first character) than 
the record described by the output FORMAT. Using the 
example from above: 

READ (3,101) A,B,C 

101 FORMAT(3F6.2) 
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This was because the leading line feed produced by BCDIO 
in the output case was stripped on input by BCDIO rather 
than retranslated to a ' 1 (space) character. 

5. The same FORMAT statement may be used to read data from 
any device, whether the device has leading line feeds 
(mass storage, paper tape, etc.) or not (terminal, card 
reader, etc.). 

The problem with this method, of course, was the need to use 
a different FORMAT statement for writing and reading the same 
record. While this restriction may be annoying, it did not 
appear to be a violation of the USA FORTRAN standard, X3.9 1966 

7e1.3.2 READ and WRITE Statements 

(page 16, col. 1, line 3) 

Records may be formatted or unformatted. . . . When an 
unformatted or formatted READ statement is executed, the 
required records on the identified unit must be, respec¬ 
tively, unformatted or formatted records. 

This states that once a record has been written with a FORMAT 

statement, it must Bo read with. a. FORMAT statement, but the 

FORMAT statements need not be the same. 

In the January 27, 1975 revision of the ANSI FORTRAN standard 
(X3J3/61 FORTREV 75-01-27), there is an interesting statement 
concerning the use of column 1 for carriage controls 
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12*9*5*2*3* Printing of Formatted Records 

The transfer of information in a record to certain devices 
determined by the processor, is called "printing* 11 If a 
formatted record is printed, the first character of the 
record is not printed* The remaining characters of the 
record* if any* are printed in one line beginning at the 
left margin* 


12„9 * 5 * 2 * 3d 


A PRINT statement does not imply that printing will occur 
and a write statement does not imply that printing will 
not occur* 

OPERATION ON DOS-15 V3A000* DOS-15 V3B000* RSX PLUS III VIA 
AND RSX PLUS III V1B 

Beginning with the version 44 FORTRAN system (May 1973) a 
subtle* but far-reaching change was made to BCDIO* The pur¬ 
pose for the change was to make it possible to read and write 
the same record on mass storage devices using the same FORMAT 
statement* While this was a noble enough goal* the modifica¬ 
tions were not properly researched or documented* 

The change implemented was to simply convert a line feed char¬ 
acter to a space character on input, before beginning to 
process the record* This produces an action complementary 
to that taken on output and does in fact achieve the immediate 
goal* 
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For example: 

WRITE (3,100) A,B,C 
100 FORMAT (IX, 3F6.2) 

READ(3,100)A,B,C 

The above example will actually write then read a file using 
the same format. 


PROBLEM: 

Obviously, making a change such as this one without providing 
adequate user documentation and conversion aids causes a user 
compatibility and conversion issue. Aside from this problem, 
there is another concerning device independence. 

Clearly, if BCDIO is going to convert a leading line feed to 
a space on input conversions, this extra space must be accounted 
for in the associated FORMAT statement. For purposes of dis¬ 
cussion, assume this extra space is handled by a "IX" conver¬ 
sion. Now, an attempt is made to read a record in the follow- 

ing format; 


XXX.XXXXX.XXXXXoXX 
The FORMAT statement might be: 
FORMAT(3F6„2) 
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If the record is on a mass storage device and the operating 
system is DOS-15 V3A000* the FORMAT must be: 

FORMAT(IX *3F6 0 2) 

However, to run this program with the card reader as the 
input device rather than disk* the program may not run as 
the input device anticipated. Assuming the three values 
to be converted by the "F" conversion began in column 1 of 
the input cards* the program will get the wrong input values 
because there is no leading line feed for BCDIO to map to a 
space to satisfy the "IX" conversion. 

In this manner* the changed BCDIO destroys some previously 
available measure of device independence at the FORTRAN level. 
Additionally* since BCDIO was changed to recognize only a 
line feed on input and convert it to a space* if a record were 
written to a mass storage device headed by any of the other 
translated carriage control characters (i.e.* FF* DCl* or DLE)* 
these characters are stripped on input* rather than retrans¬ 
lated to a space or some other character . This created a some¬ 
what inconsistent treatment of the situation. 

In summary* the conversion created the following problems: 

1. Users of earlier systems are now faced with the prospect 
of converting programs ana/or data files. 

2. Source program mobility among PDP-15 FORTRAN users is lost* 
or at least hampered. 
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3* Input device independence to a FORTRAN program is sacri¬ 
ficed to a large extent * 

4. Using the first character of mass storage device records 
for a carriage control character is questionable at best 
and certainly of limited utility. 

5. The treatment of the first character of mass storage device 
records on input is inconsistent and a potential source 

of confusion. 

6. Use of the first character of all records for carriage 
control seems to increase the effort required when con¬ 
verting a program from another machine to run on a PDP-15. 

7. Essentially, all customers who received their PDP-15 within 
the last two years have written their programs to run with 
the changed BCDIO. 

8. Due to point 7, any further discussion of the particular 
way BCDIO was changed is now largely academic since an 
approximately equal portion of the active customer base 
is affected by changes to either the earlier or later 
versions of BCDIO. 
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ALTERNATIVES s 

Given that the problem deserves some action to completely 
solve the "same FORMAT" problem and to clear up as many of 
the attendant problems as possible, the following is a list 
of alternative solutions, 

1, Do nothing. This choice is ruled out by the given assump¬ 
tion that the situation will be improved. 

2* Go back to the old way. This option puts all burden of 

conversion on UNICHANNEL customers. It also required the 
conversion by UNICHANNEL customers with no incentive; that 
is r nothing is gained for the effort in conversion. 

3. Stay with the new way. Again, this places all the burden 
on only one group, the older customers. This approach 

also carries with it the disadvantages outlined in section III. 

4. Change BCDIO to convert all translated carriage control 
characters (20, 21, 12, and 14 OCTAL) back to their res¬ 
pective characters (-f, 0, space, and 1) on input. If one 
of the above characters is not the first character in the 
input buffer, then BCDIO will supply a space character 

at the front of the buffer. This approach will correctly 
handle the same FORMAT problem initially addressed. At 
the same time, the device independence issue is resolved. 
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The problems with this are that again, only the older 
customers are forced to change. Additionally, this would 
require a "IX" at the start of each FORMAT, which seems, 
a bit contrived™ 

5, Change BCDIO so it does not perform carriage control trans¬ 
lation on output to nonprinter devices, leaving the con¬ 
version as is to printer-type devices, and so that on 
input all carriage control codes (12, 14, 20, 21, etc™) 
are dropped™ This solves the different FORMAT problem 
and restores device independence™ This solution involves 
conversion also, but it requires everyone to do some amount 
of work to come up to the new standard™ 


THE PROPOSED SOLUTION s 

It is our opinion that the most desirable solution is the last 
alternative* It is the most consistent with the spirit of the 
ANSI standard with other large scale computer systems and with 
many other DIGITAL systems* 

Under the new system, when using a nonprinter device, the same 

FORMAT statement could be used for both input and output. The 
first character of the record will not be modified by the 
object time system™ Thus, either of the following FORMAT 
statements would be acceptable for outputs 
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100 FORMAT(1X,F6„2) or 100 FORMAT(F6* 2) 

The only restriction would be that the FORMAT statement used 
for input must specify the same number of characters as the 
output statement did (in other words, they must be the same). 

In addition, device independence will be maintained, as a 
leading line feed (produced by input from an old-style disk 
file, for example) will be simply dropped, making the record 
appear the same as one from the card reader* 

The most important considerations are those concerning the 
conversion efforts involved* This change can be discussed 
relative to converting the following classes of items: 

1. DOS VIA,V2A programs that both write and read files. 

2. DOS VIA,V2A programs that only write files. 

3. DOS VlA,V2A programs that only read files. 

4. DOS VIA,V2A programs that do no file I/O* 

5. DOS VIA,V2A data files. 

Go DOS V3 programs that both write and read files. 

7. DOS V3 programs that only write files. 

8. DOS V3 programs that only read files. 

9. DOS V3 programs that do no file I/O. 

10. DOS V3 data files. 

The following sections discuss the conversion procedure for 

each of the above cases. 
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1. DOS VIA,V2A programs that both read and write a file. 

For these programs, file I/O FORMAT statements are of the 
following type: 

WRITE(1,100)A READ(1,101)A 

100 FORMAT(IX,F6.2) 101 FORMAT(F6.2) 

The recommended conversion is to eliminate the first 
character conversion in the FORMAT statement. 

WRITE (1,100) A READ (1,101) 

100 FORMAT(F6.2) 101 FORMAT(F6.2) 

Or simply use the READ FORMAT statement for output also. 

2. DOS VIA,V2A programs that only write files. 


The some conversion as used in 1 above: Delete the IX 
or its equivalent in output FORMAT statements. 

3. DOS VIA,V2A programs that only read files. 

No conversion is required. 

4. DOS VIA,V2A programs that do not file I/O. 

No conversion is required. 
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5. DOS VIA,V2A data files. 

No conversion is required; however, files generated under 
V2A will have a leading line feed character on each record. 
While these do no harm being read under either the old or 
new system, they could be deleted for aesthetic reasons. 

6. EOS V3 programs that both write and read a file. 

No conversion is required for these programs, but it is 
suggested for reasons of device independence and aesthetics. 
File I/O statement for V3 programs would have the forms 

WRITE(1,100)A READ(1,100)A 

100FORMAT(lX f F6.2) 

If the IX (or equivalent) were dropped from all file 
I/O FORMAT statements, device independence with nonmass 
storage devices would be restored, as well as saving space 
on the mass storage medias 

WRITE(1,100)A READ(1,100)A 

100 FORMAT(F6* 2) 

7. DOS V3 programs that only write data. 

No conversion is required, but the same considerations 
apply as in 6 above. Note that a user should generally 
change all programs if he changes any. Again, this 
conversion is highly desirable. 
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8. DOS V3 programs that only read files. 

Case 1: Reading old files 

Since a leading line feed is no longer converted to a 
space on input, these programs must be Modified to reflect 
this change. The recommended conversion will be to delete 
the IX or its equivalent from all file input FORMAT state¬ 
ments . 

Case 2: Reading new files 

Since a blank is no longer changed to a line feed on 
output but is left a blank, there are no changes required. 
However, it is strongly recommended that all mass storage 
files no longer allocate the first character for carriage 
control, so if the programs which wrote the files have 
been changed as recommended, then the programs which read 
the files must be changed also. 

9. DOS V3 programs which do not file I/O. No conversion is 
required. 

10. DOS V3 data files: 

If the programs are converted as recommended, no change to 
the old data files is necessary. However, if the carriage 
control space is kept in all file FORMAT statements, then 
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all old data files will have to have leading line feeds 
converted to spaces. 

The careful reader will have noticed that in all previous 
systems, it was possible to assign a disk to a FORTRAN logical 
unit which may have usually been assigned to a line printer. The 
resulting file could then be PIPed directly to the printer. Under 
the new system, this would produce a single spaced listing with 
the ASCII carriage control character being printed in column 1. 

This is because the ASCII code to internal carriage control code 
translation is no longer being performed by BCDIO to a mass storage 
device. 

To retain this capability, a new switch is being added to 
PIP which can be used on a TRANSFER command to perform the 
standard FORTRAN carriage control character translation. 
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Note that paper tape is being considered as a nonprinter 
device and* as such* will not have carriage control trans¬ 
lation performed by BCDIOHowever* some users rely on the 
off-line listing of paper tapes on an ASR teletype,, This 
requires that each data record is bounded by a Line Feed 
and Carriage Return* Fortunately* this capability is retained* 
since the punch handler preceded each record with a Line Feed 
if it does not already have one* Although this scheme will 
prevent the correct off-line listing of overprinted* double¬ 
spaced* and top-of-form records* these features never worked 
i in the past either* since the special internal carriage control 
codes were not recognized by the ASR terminal* 
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Programming Note to Eliminate Carriage Return 


There is a FORTRAN programming technique to effectively 
eliminate the carriage return following a WRITE to the 
teletype. Follow the query line with an integer (using Al 
format) which is initialized with an altmode (in 7 bit ASCII). 
If a READ is desired at the end of the line, it must be 
through a .DAT slot differing from that on which the WRITE was 
issued (which avoids a relNIT by FIOPS). Also, the READ .DAT 
slot must have been previously INITed (done, for example, 
by a REWIND). 


DATA IALT/#764jZf00/ 

REWIND 3 

WRITE (4,400) IALT 

400 FORMAT (IX, 'NUMBER PLEASE: 1 , Al) 
READ (3,) N 


END 

This results in a FOCAL type read, viz, 
NUMBER PLEASE: 
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Using System Buffers for FORTRAN OTS Double Buffering 


Tils object of double buffering FORTRAN I/O is increased through - 
put by increased I/O computation overlap. The price paid for 
this performance increase is less free memory for user programs. 


The memory space required for double buffering is requested 
from the pool of system buffers via .GTBUF macros. This means 
that users will generally require more buffers to be allocated 
than were necessary in older systems. 

Different devices are buffered in different ways. First, disks 
are not double buffered at all, owing to their speed. 

Second, one system buffer, usually 500s words, is Partitioned into 
as many individual line buffers as possible for all other 
devices except DECtape and Magnetic tape. These line buffers 
are partitioned as each device is used, and the length of the 
line buffer allocated is determined by the maximum buffer 
size returned t>y each handler in. the a XNIT macro® 

Due to th0 complexity of recovering and reallocating space in 
this system buffer, the device line buffer remains allocated 
even after it is closed via ENDFILE or CALL CLOSE. When all 
space in this buffer is allocated, any further devices which 
are opened are simply not double buffered. No indication of 
this status is available to the FORTRAN programmer. 


Finally, in the case of DECtape and Magnetic tapes, one entire 
system buffer is allocated via .GTBUF each time a new tape unit 
is opened. This is of course required due to the long record 
lengths possible with these two devices. Again, for reasons 
of simplicity and efficiency these double buffers are not 
returned when the devices are closed. 
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Using System Buffers for FORTRAN OTS Double Buffering 


As an example of the number of buffers used for a given program, 
consider a hypothetical program which uses two disk files, one 
DECtape file, the line printer, and card reader* This program 
will require a minimum of five buffers if all devices are to 
be open simultaneously* Recall that one buffer is used by the 
disk and DECtape handlers for each active file* 

There will be an additional buffer for the DECtape double buffers, 
plus one buffer for the line printer and card reader double buffer 
for a total of 5 buffers* 


Note that if users have written special handlers to be used 
with FORTRAN I/O statements, the handlers must return a valid 
maximum buffer size with the .INXT macro. Also, if a user 
determines the increased overhead in FIOPS and system buffers 
not to warrant the increased performance, double buffering may 
be assembled out of the OTS modules by following instructions 
in the Assembly Parameters section of the XVM/DOS Installation 
Guide. 
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Modes of Statement Function Variables 


PROBLEM: 

IMPLICIT mode declarations of variables appearing in a 
Statement Function definition fail, i.e., these variables 
will assume default mode. 


SOLUTION: 

To circumvent this compiler error, use an explicit mode 
declaration for such variables. 
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SOFTWARE DISBMCH 


Programming to Avoid Incorrect Mode Typing of Functions 
Declared EXTERNAL 


PROBLEM: 

The compiler is presently typing as INTEGER any function 
named in an EXTERNAL statement. This has bad effects only 
where a call to such a function is generated in the same 
program in which it is declared EXTERNAL and where the 
function should not generate an INTEGER result. 


RESTRICTION: 

Restrict your use of the EXTERNAL statement to 
naming functions that are used only as subroutine or other 
function parameters; despite the fact that they are 
thought to be INTEGER by the main program, the correct 
address of the function will be passed. However, if a 
function is involved in some program, do not declare it 
an EXTERNAL statement in this same program. The function 
will then retain its EXTERNAL characteristic (a fact that 
is determined by the compiler by the context in which it 
is used ), will not lose its mode, and can be passed as a 
subroutine parameter. 
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SOFTWARE DISBMCH 

XVM/DOS 



Variables Declared INTEGER are Typed as LOGICAL 

PROBLEM: 


Variables explicitly declared INTEGER will 
be typed as LOGICAL„ This causes problems 
data directed output of such variables• 

actually 
only in 


SOLUTION: 

To avoid the problem do not use the explicit INTEGER 
declaration for variables that will be output with 
data directed WRITE statements. 
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SCffrmBE DISBMCH 


DOUBLE INTEGER Literals Incorrectly Defined 


PROBLEM: 

Large magnitude negative DOUBLE INTEGER literals.are 
being incorrectly defined. This problem will exist, 
for example, in a DATA statement initialization of a 
DOUBLE INTEGER variable. 


SOLUTION: 

To avoid the problem, define the literal as a positive 
value and negate in an assignment statement, as follows: 

DOUBLE INTEGER DI 
DATA DI/1234567/ 

© 

© 

© 

DI = -DT 
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Transferring Control to a FORMAT Statement 


PROBLEM: 

The Fortran compiler fails to flag as an error GOTOs to FORMAT state¬ 
ments . 


NOTE: 

When a FORMAT statement is compiled, the binary output begins with a JMP 
to the location immediately following the code produced from the FORMAT 
statement. Control may be passed to a FORMAT statement in a variety of 
ways. Consider the following two examples: 


J=Z 
1 = 1+1 

100 FORMAT (....) 
J=5 

100 FORMAT(....) 

J=5 


J=Z 

GOTO 100 


In either of these cases, the JMP instruction beginning the expansion of 
the FORMAT statement transfers control to the expansion of the line J—5. 
Hence, whenever control is transferred to a FORMAT statement, the FORMAT 
statement behaves similarly to a numbered CONTINUE statement. This problem 
is not something which should be of major concern to users of FORTRAN; 
however , it is something of which they should he aware. 
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Restriction of Variable Names in Named COMMON 


PROBLEM: 

The compiler is unable to differentiate a symbol table 
entry for a named COMMON block from a variable of the 
same name in the same COMMON block. 

Thus, 

COMMON BLKS/BLKS,.../ 
will generate >04C< errors. 


RESTRICTION: 

Since the name of a named COMMON block is not actually used 
in a FORTRAN program, simply change the COMMON block name to 
a unique symbol. This same change must also be made to every 
subprogram which references the named COMMON block. 
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SOFTWARE DISBMCH 


Displaced Error Reports 


PROBLEM: 

Error messages may be printed several lines below the 
line in which the compiler detected the error. 

The problem results from the fact that comment lines are 
not detected by the main logic of the compiler. Thus, error 
reports will be displaced by the number of comment lines 
following the line in error. 


RESTRICTION: 

Any errors detected by the compiler for a given line will be 
printed after any comment lines which may follow the erroneous 
line. 
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End of Compilation Message 


TEMPORARY RESTRICTION: 

The FORTRAN compiler outputs the End of Compilation message 
twice if .DAT -12 is assigned to CM or TT. 
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Programming Note Regarding Argument Address GET Routine, .DA 

Because of the multiple entry feature in FORTRAN XVM, the argument address 
fetch subroutine .DA does "double indirection" when both fetching and 
storing addresses passed from a main program to a subroutine. Users 
should be aware that if bit zero in the storage address cell of the 
subroutine is set, another level of indirection is performed. Thus, 

MACRO subroutines using the argument address cells as scratch cells may 
cease to function under FORTRAN XVM* 


Example: 


SUBR 


A 

B 

C 


.TITLE 

MACRO 

SUBROUTINE CALLED FROM FORTRAN 

.GLOBAL 

SUBR,. 

DA 

XX 


/ENTRY POINT 

JMS* 

.DA 

/CALL ARG. GET ROUTINE 

JMP 

. +4 

/EXPECTING 3 ARGUMENTS 

. DSA 


/ADDR. OF FIRST 

. DSA 


/ADDR. OF SECOND 

.DSA 


/ADDR. OF THIRD 


After the return from .DA, locations A, B, and C contain the addresses 
of the arguments to be passed. It is a common practice to then execute 
a statement of the following forms 


LAC* A /GET THE ARGUMENT ITSELF 

DAC A /AND PUT IT IN POINTER WORD. 


If the value of the first argument happened to be negative, then bit 0 
would be a 1. The next time SUBR is called, .DA would interpret the fact 
that hit 0 of the pointer - word A is a 1 to mean that the address of the 
argument should not be put in the pointer word itself, but that the 
address is to be put in the word whose address is in the pointer word. As 
a result, this programming practice will cause unpredictable results. 
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Numerical Restrictions in AMOD and DMOD 


PROBLEM: 

In the existing FORTRAN documentation there is stated a 
restriction on the range of values that AMOD and DMOD can 
accommodate. In either of these, for a call of the form 
AMOD (ARG1,ARG2 ), one of the internal operations is com¬ 
puting the result of ARG1/ARG2 , and then converting this 
result to a single precision integer. This latter opera¬ 
tion limits the useful range of ARG1/ARG2 to less than 
2 17 , i.e., less than 131072. When this condition is not 
met, an OTS 11 error occurs, the program continues, and 
the results of AMOD or DMOD are not generally predictable. 


SOLUTION: 

This restriction can be relieved somewhat by the following 
example. (This is not to be construed to be a 

supported software feature of the FORTRAN Object time system). 
Considering the case of DMOD, code and compile: 

DOUBLE PRECISION FUNCTION DMOD (ARG1,ARG2) 

DOUBLE PRECISION ARG1,ARG2, D 

DOUBLE INTEGER J 

J = ARG1/ARG2 
D = J 

DMOD = ARG1 - D*ARG2 

RETURN 

END 


software product 

XVM/DOS 

vr RE 

VI 

>lON 

.A 

COMPONENT 

FORTRAN OTS 

VERSION 

N/A 

EDIT 

N/A 

SUBPROGRAM OR ADDITIONAL INFORMATION 

AMOD, DMOD 

SEQUENCE 

2 

PAGE 

Of- 

1 2 

NEW REPLACEMENT; 

n 1 I 

ARTICLE 

ORIGINAL DATF 

December 1972 






Numerical Restrictions in AMOD and DMOD 


Explicitly state this program file name in the loader com¬ 
mand string, and it will be loaded instead of the FORTRAN 
Library routine DMOD. It extends the largest useful value 
of ARG1/ARG2 to be less than 34,359,738,368. 

An equivalent routine may be written to replace AMOD by 
replacing "DOUBLE PRECISION" with "REAL" and "DMOD" with 
"AMOD" at all locations in which each appears. 
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IOPS31 Errors When Referencing the Last Element of an Array 


PROBLEM: 

Under certain circumstances an I0PS31 error can occur when 
referencing the last element of an array which is in a common 
block located in extended memory,, if that element is the last 
word in memory. 


DISPOSITION: 

A temporary solution is to either lower the logical memory size 
(MEMSIZ command) or add a dummy variable at the end of the common 
block in question. 
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First Character of Each Record Sometimes Truncated 
On Mass Storage Files 


PROBLEM: 

If a file is created on a mass storage file, then eventually 
reopend for output (to be rewritten) in the same core load, 
the first character of each record may be truncated as it is 
written into the new file. This problem pertains only to 
output files? a file may be reopened for input with no difficulty. 



SOLUTION: 

Due to a coding error in FIOFS, not all of the device information 
is retained in some internal tables following a CLOSE * These 
source changes to F.IGPS, making the edit number 043, correct this 
problem. 


/EDIT **042 ?4-nhv»7* 

/ Ann & MFVJ ASSEMBLY PAHA-kFU*# UNOOBU to suppress 

/ double EilFrfQlNGf AND make DOUBLE BUFFER THE DEFAULT® 



FJX Rim jU e rv$K ROUTINE 
OF V i r; E « R I t t 0 OFT LOST 
OUTPUT . 


hhlLH CAUSED THU ? NON^PRINTER 
I Y A FILE ‘wA$ RE-QPENEO FOR 
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First Character of Each Record Sometimes Truncated 
On Mass Storage Files 


C*L « 

.DSft 1 
e OS A FCFRo 

o S A ft 

_ LAC SLOT 

_JMS . PRK 

,IFDff *nBi. 


/. JNIT IGPi ROUTINE. 


/(RK9-CM3) RE-BUILD DIBITS 

/(PKB-043) TO REFLECT 'NON-PRINTER' DEVICE 




L 4 C .FpS /TfST FOR TTY 



SAO (o /I Ji.f puFfER size or TTY 

LRS 1 /XF ¥*$, SET BIT 1 

LRS 1 ZeEt oIT C TO INDICATE 1ST TIME 

AND (7 C>PP'.'.f 

DAC RW /Oo TN LATER 

/ 

LAC SLOT 

tap c.rtabi-i 

OAC T., 

F C » , 5 LAC* T.1 

SAO (777777) 

JMP FCl.A 

SZA 

IMP Fr.„„P 
eENDC 

/(RKP-M3) 

J (RKB-IA43) Tmf FfiLl.RvjvG FOUR LINtS WERE DELETED! 


.IFPCF 5!n0e l *i 

LAC slot 

JMS .OSK /IF life 

.FRDc 

< I f u ft f x n n i 

LAC .POKE / CRRB" 

S? A 4 CLC 

JMP FC..P /IT'S 

LAW /T^ST FOR MS 

TaO ,Fr6 


/IF DEVICE IS A DISK, AC a -1 ON RETURN 

/(RKB-043) GET INICATOR FROM .OSK 
/IT'S A DISK f INSTAL A -1 
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First Character of Each Record Somtimes Truncated 
On Mass Storage Files 


ms? TRY FOR A FULL SUFFER 


SMA 

JMP FC..F 
LAC RUFE^'D 
S? A /I<5 THE RF A M0N-M5 SUFFER YF.T? 


FC11 


G> 


FC1M 


PC 11 6 5? 


.a 

/YES? 

TRY ID 

PARTITION it 

(FURTHER) 

SAD 

C 777777 ) 

/CLEAR 

AC 

IF NOT A 

D3K 

CLA 






DAC 

* D S K F 





“TTAC 

FC9 

/ (RNb- 

0 43) 

oer the 

DAT SLOT 
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CSTAB-1] 

i / ( R K B 

-043 

) FIND the STAb ENTRY 
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USE THIS 
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FC4 

/ (RKb- 

*43) 

IS THIS 

SLOT BEING RE-OPENED? 

52 A 


/ ( RK b« 

043) 

SKIP IF 

YfcS 

JMP 

F C U * 2 

/ ( RN b«® 

043) 

NO, ITS 

ALREADY OPEN 

LAW 

-325 

/ (RKb- 

043) 

Nttt) TO 

re-determine 

TAD 

» FC6 

/ (RKH- 

043) 

DEVICE TYPE 

SNA 


/(RKB- 

043) 

SKIP If 

NUT OT, NT, HK, RP, OK 

JMP 

pcn.i 

/CRKH- 

043) 

ITS A DISK OR TAPE UNIT 

A AC 

375-52 

/CRKH- 

043) 

IF BUF S 

1IZE IS 62, ITS PP OR PR 

SNA I 

OLA 

/CRKB- 

043) 

SKIP IF 

NOT PP OR PR 

LAC 

C4SH'fl0) 

/ (RKB- 
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SET THE 

* NON-PRINTER f BIT 
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DIBITS 
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Cl KNOW 
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a D S K F 
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old disk flag 

JNP* 

® DSK 






/U$K TAbLfe 200003 OR 300000 BN 
/U JSK PRESENT e 77 77 77 ENTRY I 
/DISK PRESENT 
DSKYbL** 

« REP T OKTbSZ 
0 


TRY INDICATES SLOT @FSTAT s D AND 
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*R 
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Programming Note 


Radix 50 q is a technique used by the MACRO Assembler and 

the FORTRAN Compiler to condense the binary representation 
of symbolic names in symbol tables. It is described in 
Appendix C of the Linking Loader Utility Manual. 

The Radix 50 q table on the following page should be 
added to the description in the Linking Loader Manual. 
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RADIX 50g VALUES 


■ X— 


-X- 


——X 

A 

003100 

A 

000050 

A 

000001 

B 

006200 

B 

000120 

B 

000002 

C 

011300 

C 

000170 

C 

000003 

D 

014400 

D 

000240 

D 

000004 

E 

017500 

E 

000310 

E 

000005 

F 

022600 

F 

000360 

F 

000006 

G 

025700 

G 

000430 

G 

000007 

H 

031000 

H 

000500 

H 

000010 

I 

034100 

I 

000550 

I 

000011 

J 

037200 

J 

000620 

J 

000012 

K 

042300 
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000670 
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000013 

L 


L 

000740 
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000014 
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050500 
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000015 
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N 

000016 


0 
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001130 
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000017 
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001200 

P 

000020 

Q 
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Q 

001250 

Q 

000021 
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001320 
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000023 
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Incomplete Loading of Subroutines with Multiple Entry Points 


PROBLEM: 

In subroutines with multiple entry points, if the mutiple entry 
point ,GLOBAL definitions are interspersed with executable code 
(unavoidable in FORTRAN routines with multiple entry points) ,■ 
the following situation exists. 

If the routine calling the subroutine does not reference the 
first entry point, the Loader will incompletely load the sub¬ 
routine, The Loader loads from the first referenced entry point 
to the end of the program unit. 


RESTRICTION: 

A dummy reference to the first entry point must be included 
to cause complete loading by the Loader. 
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BATCH .DAT Slots 


PROBLEM: 

When the BATCH device is used by a user program but is not 
assigned to any of the Loader .DAT slots (-1, -4 or 5), two 
copies of the BATCH device handler will be loaded. The first ref- 
erence to the second of these handlers will result in a fatal 
system error. 


SOLUTION: 

This situation can be avoided by either assigning to BATCH 
a device not used by the user program or by assigning the 
BATCH device to one of the Loader .DAT slots. 
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xvm/dos 


BATCH I/O Device Use 


PROBLEM: 

When a user program that is loaded via GLOAD within a BATCH 
stream uses the locations between those pointed to by .SC0M-F2 
and bSCOM+ 3 but does not use the BATCH device, i.e., no .IODEV 
was issued, a fatal error can occur upon return to BATCH« 


SOLUTION: 

This error can be avoided by loading, along with the user programs, 
a dummy program containing the instructions: 

. IODEV n 
.END 

where n is a .DAT slot previously assigned to the BATCH device. 
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XVM/DOS 


System Build Leaves Erroneous .DAT Assignment 


PROBLEM: 

Because XVM/DOS systems generated by the BUILD program are left 
with .DAT-4 ASSIGNed to a default UIC of SYS, attempts to 
load programs are directed to either the PAG or BNK UFDs. 
ince user programs are normally not kept in either the NAME 
or BNK UFDs, attempted program loading results in an I0PS13 
error. 


SOLUTION: 

SGEN the system to modify .DAT-4 as follows: 
>A SY <UIC> -4 
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XVM/DOS 


SOFTWARE DISFAICH 


Programming Note on Use of T Switch 


PROBLEM: 

When using the T-switch, a discrepancy in the page count 
may occur where the user has a .LTORG in his program 
with many forward referencing literals. The forward 
referencing literals waste space and should be removed— 
one location is reserved per forward reference. The page 
count discrepancy occurs because the page count is adjusted 
during pass one to reflect the total literal count. If the 
count is smaller after pass two (forward references have 
been defined ), the page count is likely to be inaccurate. 
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XVM/DOS 


MACRO E Switch Does Not Give Correct Lines in Console Device 
Under BOSS 


PROBLEM: 

When using the MACRO E switch and running under BOSS, the error 
lines printed on the console terminal are not correct. They 
are most often a combination of several legitimate error lines. 


SOLUTION: 

Avoid using the MACRO E switch while operating under BOSS. Since 
the error lines are correctly listed on the printer, this 
should only be an inconvenience. 
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XVM/DOS 


Edits to Bring MACRO to XVM/RSX Release Level 


PROBLEM: 

Because of the time between the releases of XVM/DOS and XVM/RSX, 
the sources of MACRO released with each system no longer match. 


SOLUTION: 

The following source changes to MACR15 118, which pertain 
only to the RSX version of MACRO, should nevertheless be 
made to the DOS version to keep both versions identical. 
These edits produce MACR15 120. 


/ 

116 

25/N0V/75 

f JMW5 

/ 

117 

2S/NQV/7B 

f JmW] 

/ 

116 

B4/0EC/7B 

f J“W] 

/ 

i 19 

17/0FC/7B 

t J“W] 

/ 

12® 

30/OFC/75 

(JMW] 


.WAIT A FT Eli 'El OUTPUT. 

CORRECT A RSX ERROR MESSAGE. 

ANOTHER GARBAGE COLLECTOR FIX1 
2 RSX CORRECTIONS. 

ANOTHER RSX CORRECTION, TO ALLOW BATCHING, AS BEFORE, 


/THERE are SPVPRAL ASSEMBLY PARAMETERS FOR MACROS 

eLMS the STANDARD SYSTEM VERSIONS 

PAM BE DEFINED TO A DESIRED PATCH SIZE (DEFAULT ♦ 40] > 
p L nS A VERSION TO BE RUN WITH DOT (CR£F BECOMES A SUBROUTINE ]t 
TNpL"0ES DEBUGGING CODE FOR VERIFICATION OF MACRO DEFINITION TABLE. 

WTU INCLUDE THE ASS LOADER WHICH LOADS AT 1776*0 RATHER THAN 17720. 
"DUCES THE RSX VERSION OF MACRO. NOTE THAT THERE ARE SEVERAL 


1. NfJNP Vis 

2. XPATCH 

3. XBIn vis 

4. XdEpUG 

5. XDmACPO 

6. XRSX PR' 
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XVM/DOS 


Edits to Bring MACRO to XVM/RSX Release Level 


NOTIT*. 

.ENOC 
LAC VSwCH 
OZM 3AVEF 
SNA 

JHP .*4 
LAC al^ptn 
SZA 

SET NSWCH 
.IFOFF XRSv 
OZN POTSW 
LAC TSWCH 
SNA 

JMP .4-3 
LAC (OATl2 
JUS ATACH 
a ENDC 

.IFUno XRSy 
LAW =3 
0AC FLDSN 
• ENOC 


-.ife 

5EF XRSy 


flosw 

uc 

SNA 

PSWCH 

JmP 

NPSW 

uc 

(OAT!0 

JMS 

S2& 

HINFRQ 

1 

FLOSW 


/IF X AND L ARE USED FORCE 1 N', 


/SET NO EXIT ON CR - ALTMODE SWITCH. 
/SEE IF NEED TO ATTACH. 

/NO - DON 'T ATTACH. 

/yes - ATTACH OUTPUT LISTING DEVICE. 


/CJMW: 12B) THE % HAD BEEN LEFT OUT AND BATCHING DIDN'T WORK, 
/CLEAR THE FILES COUNT, 

/PARAMETER FILES? 

/NO - DON'T COUNT IT. 

/DO A HINF ON THIS LUN TO SEE IF IT IS 
/ file STRUCTURED. 

/0s NON DIRECTORIES. 

/FILE STRUCTURED - COUNT THE FILE, 
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XVM/DOS 



NXTCHR JMS GETChD 

sad 

jmp nxtchR 

_w JFUNO XPSy 

SAD CD“H» 

JMP NXTCHR 

-*~.ENDC 

OZM PRvCHR 
SKP 

ChDSUB .IMS GEtCmD 
sad 149 

JMP CMnEXT 
SAD KOMMA 
JMP fe||MDuN 

jms mtp 

JHP CMflSUB 
CMDEXT Sad pRvchR 
JMP PA*AI.L 
OAC PRVCHR 
UAH -3 


/IGNORE LEADING BLANKS/ 

/CJMWS1193 SINCE RSX CAN BATCH 
/V7C,V70 PATCH 

/IGNORE COHHAS in BOSS MODE 
/(JKW:1195 NEED THE COMMAS. 
/PSEUDO COUNTER FOR SPACES. 


ASSEMBLIES 


/GET A CHAR AND RETURN IF NOT DELIMITED, 


/DONT PACK AFTER 9 CHARS ARE IN, 
/GET NEXT CHAR 

/LINE DELIMITED FIND CR OR ALT, 










XVM/DOS 


Edits to Bring MACRO to XVM/RSX Release Level 


CHEF 


.SIXBT /CRpF/ 

.EMOC 

.IFDFF 
JMS* CPFF 
JMP PASS? 
.ENDC 
.ENDC 

.IPDEF XRSy 
JMS wiiTl2 
LAC FILNM3 
A AC -l 
CAC* L!S 
LAC .SFK14 
JMS SETS® 

LAW -6 


/(JMMI106} MAKE CREF A SUBROUTINE FCR MACRO UNDER DDT. 
/CJMWI106) 

/)JHW 8106) 


/WAIT FOR LISTING OEVICE, 

/MOVE the file NAMES for cref into the resident area. 


/MOVE BOTH NAMES, 


JMS MQVAIJT 

LAC fFSWCH /MOVE THE REST OF THE PARAMETERS, 

JMS SETS* 

LAW »$? /CJMW!113) 

JMS MOVAIIT 

jmp* macpIm /RETURN TO RESIDENT CODE TO DISPATCH TO CREF, 

.ENDC 

.TITLE .EmO MESSAGES AND UTILITIES 
.IFOEF XRS¥ 

■*-LRCR-ERRLIn*?/I 000*2*2 /CJMWS119J 


(9 


.ENDC 
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XVM/DOS 


SOFTWARE DISPATCH 


Teletype Handler •INIT Function Limitations 

. ,, ■ .... I ^ ‘ ,Vf 11 11 ' ' I .” 


PROBLEM: 

A .INIT issued to the teletype handler will not cancel a 
.READ/.WRITE which is in progress. 

The reason for this problem is that after the CAL pointer 
has been saved and the argument pointer incremented, the 
I/O underway switch is tested and, if set, the 
program loops back to the CAL. 


SOLUTION: 


.SCOM location SC.CTT contains an instruction to clear 
the teletype busy switch. IF a program desires to 
abort the teletype I/O, it should execute the following 


SC.CTT=135 
XCT* (SC.CTT) 

FOLLOWING this perform a .INIT to the handler. 


SOFTWARE PRODUCT 

XVM/DOS 


COMPONENT 

MONITOR 


SUBPROGRAM OR ADDITIONAL INFORMATION 

RESMON 


NEW 

□ 


REPLACEMENT ARTICLE 


CD 


Vf HSlON 

VIA 


VERSION 

VIA. 


SEQUENCE 

1 


E DIT 

213 


PAGE 

1 ° f 1 


ORIGINAL DATE 

October 1973 








.DAT -12 Set Up 


PROBLEM: 

While exiting a CUSP and returning to the nonresident Monitor 
there exists a period of time when typing tc will cause .DAT 
-12 to be set up incorrectly. This problem is seen as a NON- 
\ EXISTENT HANDLER NUMBER message when a REQUEST command is 

issued. If a program tries to use .DAT -12 while in this 
condition, the following situations arise. 

If LP OFF, references to .DAT -12 go to the teletype. If LP ON, 
unpredictable results occur, such as IOPS0. The critical period 
exists from the issuance of the tC or .EXIT until the nonresident 
Monitor starts typing the XVM/DOS V1A000 message. 


RESTRICTION: 

This problem in the resident monitor will not be fixed. To 
clear up the problem with .DAT -12, do anything which restores 
the default .DAT settings. This occurs whenever exiting 
from a program with KEEP OFF or after typing LOGIN or LOGOUT 
commands. 

For example: . 

$K OFF J 
$PIP ) 
tc 

XVM/DOS V1A000 

$ 

The problem can also be corrected,by performing an ASSIGN to..DAT-12. 


/Type any Cusp name 

/Pause one second., then type iC 

/Now *DAT -12 is set up correctly 
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XVM/DOS 


SOFTWARE DISRAJCH 


MICLOG Before Patching on Disk 


PROBLEM: 

The PATCH manual does not mention the need under XVM/DOS 
to MICLOG before patching on disk. 


SOLUTION: 

Make the following changes to the manual. 

1. Replace the first sentence of Section 6.2.1 ".DAT Slot 
Assignments" on page 6-1 with: 

When operating in XVM/DOS and about to make patches to 
a disk, first log in under the Monitor ID Code (MICLOG). 
Then, for all operating systems, make the .DAT slot 
assignments in Table 6-1 prior to loading the PATCH 
program. 

2. Add the following error message to Table 6-4 on page 
6 - 6 : 

.DAT-14 NOT PATCHABLE 

This means that the user failed to MICLOG prior to 
loading PATCH in a XVM/DOS system. 
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XVM/DOS 


SOFTWARE DISBMCH 


FORTRAN Programs Cannot be Made System Programs 


PROBLEM: 

Section 3 of the PATCH manual describes how relocatable 
user programs (those normally loaded and executed by the 
Linking Loader) can be converted into SYS (System) 
programs. This is a useful capability because it allows 
programs to be called and executed by a direct command 
to the Monitor, which decreases loading time and teletype 
interaction. However, the manual does not explicitly 
say that all FORTRAN programs (or ALGOL for that matter) 
are excluded. This fact is implicit in the restriction 
of Section 3.2.2. that the binary not contain external 
.GLOBL references. 


SOLUTION: 

1. Add text to line 1 of Section 3.1 so that the line 
reads: 

A PATCH load function enables the user to convert 
a stand-alone relocatable file (which excludes 
FORTRAN and ALGOL programs as explained in Section 
3.2.2). 

2. Add text to Section 3.2.2, item 2 on the sixth line 
from the bottom of page 3-2 so that it reads: 

not contain external .GLOBL references. This excludes 
all programs which must be linked to other binary 
routines. FORTRAN and ALGOL language programs require 
linkage to external routines and thus cannot be made 
into SYS files. 
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XVM/DOS 


IOPS0 after (H) Copy to System Disk 


PROBLEM: 

When an H mode copy is put onto the system disk (DO0 or RK0), 
an IOPS0 will sometimes occur at the end of the copy.. This 
occurs only when the new system copied onto the disk is different 
than the one that originally resided on the disk. 


SOLUTION: 

The copy has been successfully completed by the time the error 
occurs. Therefore the user need only reboot the system to 
continue. 

This problem has been fixed in the PIP in the XVM/DOS VIA 
system by forcing an .EXIT to the monitor after an H mode 
copy to the system disk. Because of the complexity.of a binary 
patch (the patch is in the part of PIP overlaid during 
the copy), prior versions of PIP will not be modified. 
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Conversion from ADSS-15: Programs May Not Fit 


PROBLEM: 

When updating ADSS-15 systems to XVM/DOS, sometimes the 
user programs do not fit. This symptom has several 
possible causes: 

1. The FORTRAN OTS library has grown in average size of 
routine by about lj?-15%. 

2 There are a number of core-consuming monitor environ 
mental considerations 

- VT ON 

- Size of monitor patch area 

- Size of buffer pool 

- Size of buffers 

- Size of .DAT table 

- UNICHWSMSL TGB Buffers 

which are not present in ADSS-15. but can help 
to exhaust core quickly if not handled properly. 

3. The resident monitor itself (RESMON) has grown. 


Sometimes this size increase is just enough to force a 
device handler to be loaded in the second memory field 
(4K page) instead of the first, leaving a non-obvious 
hole in low core. 


SOLUTION: 

If this occurs, enable BANK mode operation since it ignores 
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xvm/dos 


SOFTWARE DSfWCM 


Using API Level 4 


PROBLEM: 

There is a potential timing problem when more than one routine in 
the system is using API software level 4. Since the standard XVM/DOS 
disk handler uses level 4, users must be careful to code any 
of their routines which use level 4 to avoid such timing problems. 

SOLUTION: 

The following code illustrates how to set up level 4 requests. 

The essential point is that no interrupts be allowed while 
the set up is being done. 

SETUP AND USE OF API LEVEL 4 


/ 

API.R4=404000 
SC.LV4=.SC0M+12 
.INH =705522 
•ENB =705521 
/ 

/MAKE THE LEVEL 4 REQUEST 

/ 


• INH 


/ALLOW NO INTERRUPTS 



RPL 





AMD 

(API.R4) 




DAC 

SAVREQ 

/SAVE ANY PREVIOUS LEVEL 

4 

REQUEST 

LAC* 

(SC.LV4) 




DAC 

SAWCT 




LAC 

(API.R4) 




ISA 


/MAKE LEVEL 4 REQUEST 



LAC 

(LV4INT) 

/ADDRESS OF THIS PROGRAM' 

! S 

LEVEL 4 

.ENB 





DAC* 

(SC.LV4) 

/PROCESSOR GOES INTO .SCOM+12 



SOFTWARE PRODUCT 

VERSION 


XVM/DOS 

VIA 



COMPONENT 

VERSION 


EDIT 


SYSTEM 

N/A 


N/A 

J SUBPROGRAM OR ADDITIONAL INFORMATION 

SEQUENCE 


PAGE 

OF 


API LEVEL 4 SOFTWARE 

2 


1 2 

NEW 

REPLACEMENT ARTICLE 

ORIGINAL DATE [ 

_ 


i_i 

October 

1975 









SOFTWARE DISBMCH 


XVM/DOS 


Using API Level 4 


/INTERRUPT PROCESSOR 

/ 

LV4INT 0 
.INH 

DAC SAVAC 

LAC SAVREQ /MAKE PREVIOUS LEVEL 4 REQUEST 

ISA 

LAC SAWCT 
• ENB 

DAC* (SC.LV4) /RESET.SCOM+12 


LAC SAVAC 
DBR 

JMP* LV4INT 

/ 

SAVREQ 0 
SAWCT 0 
SAVAC 0 


/RESTORE THE AC 
/AND DEBREAK 


/SAVE ANY PREVIOUS LEVEL 4 REQUEST 

/AND VECTOR ADDRESS 

/SAVE AC ON LEVEL 4 INTERRUPT 
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XVM/DOS 


System Manual Not Complete 


PROBLEM: 

The XVM/DOS System Manual (DEC~XV-ODSAA-“A--D) is incomplete in 
that Chapter 9 is not in the manual although it is referenced 
within the manual. 


SOLUTION: 

Chapter 9 will be released at a later date as an addendum to 
the manual. 
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SOFTWARE PROBLEMS OR ENHANCEMENTS 


Questions , problems, and enhancements to Digital software should be reported on a Software Performance 
Report (SPR) form and mailed to the SPR Center at one of the following Digital Offices: (SPR forms are 
available from the SPR Center.) 

Areas Covered SPR Center 


Australia/New Zealand 


Brazil 


Canada 


Caribbean 


France 


Israel 


Italy 


Japan 


Mexico 


The Netherlands 


Nordic 


Switzerland 
Spain Portugal 
Greece Bulgaria 
Romania Yugoslavia 

United Kingdom 


West Germany Austria 
East Germany Russia 
Hungary Poland 

Czechoslovakia 

United States; remainder of 
Far East, Middle East, 
Africa, Latin America 


Digital Equipment Australia Pty. Ltd. 
123-125 Willoughby Road, P.0. Box 491 
Crows Nest 

New South Wales, Australia 2065 

Digital Equipment Comercio E Industria LTDA 
Rua Batatais, 429 (Esq. Al. Campinas) 
01423-Jardim Paulista 
Sao Paulo-SP-Brazil 

Digital Equipment of Canada, Ltd. 

Software Services 
P.0. Box 11500, K2H 8K8 
Ottawa, Ontario, Canada 

Digital Equipment Latin America, Inc. 

407 del Parque Street 
Santurce, Puerto Rico 00912 

Digital Equipment France 
18, rue Saarinen 
Centre Silic - CIDEX L225 
F-94533 Rungis, France 

DEC-sys Computers Ltd. 

7 Habakuk Street 
IL-Tel Aviv 63505, Israel 

Digital Equipment S.P.A. 

Corso Garibaldi 49 
1-20121 Milano, Italy 

Digital Equipment Corp. Inti. 

Kowa Building 25 (3d Floor) 

8-7 Sunban-Cho 

Chiyoda-ku, Tokyo 102, Japan 

Equipo Digital, S.A. de C.V. 

109 Concepcion Beistegui 
Mexico 12, D.F. 

Digital Equipment B.V. 

Kaap Hoomdreef 38, P.0. Box 9064 
NL-Utrecht - Overvecht, The Netherlands 

Digital Equipment AB 
Englundavagen 7 
S-17141 Solna 
Sweden 

Digital Equipment Corp. SA 

20, Quai Ernest Ansermet 

Case Postale 23, CH-1211 Geneva 8 

Switzerland 

Digital Equipment Co. Ltd. 

Fountain House, Butts Centre 
GB-Reading RG1 7QN, England 

Digital Equipment GmbH 
D-8000 Munchen 40 
Wallensteinplats 2 
West Germany 

Software Communications 
P.0. Box F 
Maynard, MA 01754 





DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS 01754 
European Headquarters: 81 route de I’Aire, 1211 Geneva 26. Switzerland 
Digital Equipment of Canada Ltd., P.O. Box 11500 Ottawa, Ontario K2H8K8. 


DIGITAL EQUIPMENT CORPORATION, Component Group Headquarters: 1 Iron Way, 
Marlborough, Mass. 01752, Telephone: (617) 481-7400 


DIGITAL EQUIPMENT CORPORATION, Corporate Headquarters: Maynard, 
Massachusetts 01754, Telephone: (617) 897-5111 
SALES AND SERVICE OFFICES 

DOMESTIC — ARIZONA, Phoenix and Tucson • CALIFORNIA, Los Angeles, Monrovia, 
Oakland, Ridgecrest, San Diego, San Francisco (Mountain View), Santa Ana, Sunnyvale, 
and Woodland Hills • COLORADO, Englewood • CONNECTICUT, Fairfield and Meriden 

• DISTRICT OF COLUMBIA, Washington (Latham, Md.) • FLORIDA, Orlando • GEORGIA, 
Atlanta • ILLINOIS, Chicago (Rolling Meadows) • INDIANA, Indianapolis • IOWA, 
Bettendorf • KENTUCKY, Louisville • LOUISIANA, Metairie (New Orleans) 

• MASSACHUSETTS, Marlborough and Waltham • MICHIGAN, Detroit (Farmington 
Hills) • MINNESOTA, Minneapolis • MISSOURI, Kansas City and St. Louis • NEW 
HAMPSHIRE, Manchester • NEW JERSEY, Fairfield, Metuchen and Princeton • NEW 
MEXICO, Albuquerque • NEW YORK, Albany, Huntington Station, Manhattan, Rochester 
and Syracuse • NORTH CAROLINA, Durham/Chapel Hill • OHIO, Cleveland, Columbus 

and Dayton • OKLAHOMA, Tulsa • OREGON, Portland - PEMMSYLVAT1IA, Philadelphia 

(Bluebell) and Pittsburgh • TENNESSEE, Knoxville • TEXAS, Austin, Dallas and Houston 

• UTAH, Salt Lake City • WASHINGTON, Bellevue • WISCONSIN, Mil w auke e (Brookfield) • 
INTERNATIONAL — ARGENTINA, Buenos Aires • AUSTRALIA, Adelaide, Brisbane, 
Canberra, Melbourne, Perth and Sydney • AUSTRIA, Vienna • BELGIUM, Brussels 

• BOLIVIA, La Paz • BRAZIL, Puerto Alegre, Rio de Janeiro and Sao Paulo • CANADA, 
Calgary, Halifax, Montreal, Ottawa, Toronto and Vancouver • CHILE, Santiago 

• DENMARK, Copenhagen • FINLAND, Helsinki • FRANCE, Grenoble and Paris 

• GERMANY, Berlin, Cologne, Hannover, Hamburg, Frankfurt, Munich and Stuttgart 

• HONG KONG • INDIA, Bombay • INDONESIA, Djakarta • ISRAEL, Tel Aviv • ITALY, 

Milan and Turin • JAPAN, Osaka and Tokyo • MALAYSIA, Kuala Lumpur • MEXICO, 
Mexico City • NETHERLANDS, Utrecht • NEW ZEALAND, Auckland 

• NORWAY, Oslo • PHILIPPINES, Manila • PUERTO RICO, Santurce • SINGAPORE 

• SPAIN, Barcelona and Madrid • SWEDEN, Gothenburg and Stockholm 

• SWITZERLAND, Geneva and Zurich • TAIWAN, Taipei and Taoyuan • UNITED 
KINGDOM, Birmingham, Bristol, Dublin, Edinburgh, Leeds, London, Manchester 
and Reading • VENEZUELA, Caracas • YUGOSLAVIA, Ljubljana • 





